Automatic Storage Management

Automatic Storage Management (ASM) is a feature provided by Oracle Corporation within the Oracle Database from release Oracle 10g (revision 1) onwards. ASM aims to simplify the management of database files. To do so, it provides tools to manage file systems and volumes directly inside the database, allowing database administrators (DBAs) to control volumes and disks with familiar SQL statements in standard Oracle environments. Thus DBAs do not need extra skills in specific file systems or volume managers (which usually operate at the level of the operating system).

With ASM:

• IO channels can take advantage of data striping and software mirroring
• DBAs can automate online redistribution of data, along with the addition and removal of disks/storage
• the system maintains redundant copies and provides 3rd-party RAID functionality
• Oracle supports third-party multipathing IO technologies (such as failover or load balancing to SAN access)
• the need for hot spares diminishes

Contents 1 Features 2 Architecture overview 3 Implementation and usage 3.1 Overview 3.2 Setup 3.3 Startup and shutdown of ASM instances 3.4 Administering ASM Disk Groups 3.4.1 Disks 3.4.2 Templates 3.4.3 Directories 3.4.4 Aliases 3.4.5 Files 3.4.6 Checking metadata 3.4.7 ASM views 3.4.8 ASM Filenames 3.4.9 SQL and ASM 3.4.10 Migrating to ASM Using RMAN 4 Functionality 5 Striping 6 Redundancy 7 Directory Structure 8 Comparison with other LVMs 9 Advantages for database administrators 10 See also 11 External links

Features

• ASMCMD: useful for users not familiar with SQL (one can write scripts with it)

Architecture overview

ASM creates extents out of datafiles, log-files, system files, control files and other database structures. The system then spreads these extents across all disks in a "diskgroup". One can think of a diskgroup in ASM as an LVM volume group — with an ASM file corresponding to a logical volume. In addition to the existing Oracle background processes, ASM introduces two new ones - OSMB and RBAL. RBAL opens and creates disks in a diskgroup. OSMB provides the functionality of moving data between disks in a diskgroup.

Implementation and usage

Automatic Storage Management (ASM), introduced in Oracle 10g, aims to simplify the storage of Oracle datafiles, controlfiles and logfiles.

Overview

Automatic Storage Management (ASM) simplifies administration of Oracle-related files by allowing the administrator to reference disk groups (rather than individual disks and files) which ASM manages. The ASM functionality is an extension of the Oracle Managed Files (OMF) functionality that also includes striping and mirroring to provide balanced and secure storage. The new ASM functionality can be used in combination with existing raw and cooked file systems, along with OMF and manually-managed files.

The ASM functionality is controlled by an ASM instance. This is not a full database instance, just the memory structures, and as such is very small and lightweight.

The main components of ASM are disk groups, each of which comprise several physical disks controlled as a single unit. The physical disks are known as ASM disks, while the files that reside on the disks are known as ASM files. The locations and names for the files are controlled by ASM, but user-friendly aliases and directory structures can be defined for ease of reference.

The level of redundancy and the granularity of the striping can be controlled using templates. Oracle Corporation provides default templates for each file-type stored by ASM, but additional templates can be defined as needed.

Failure groups are defined within a disk group to support the required level of redundancy. For two-way mirroring a disk group might contain two failure groups, in which case individual files are written to two locations.

In summary ASM provides the following functionality:

• Manages groups of disks, called disk groups.
• Manages disk redundancy within a disk group.
• Provides near-optimal I/O balancing without any manual tuning.
• Enables management of database objects without specifying mount-points and filenames.
• Supports large files.

Setup

The following initialization parameters relate specifically to an ASM instance:

• INSTANCE_TYPE - set to ASM or RDBMS depending on the instance type. The default is RDBMS.
• DB_UNIQUE_NAME - specifies a globally unique name for the database. This defaults to +ASM but must be altered if one intends to run multiple ASM instances.
• ASM_POWER_LIMIT - the maximum power for a rebalancing operation on an ASM instance. The valid values range from 1 to 11, with 1 being the default. The higher the limit the more resources are allocated resulting in faster rebalancing operations. This value is also used as the default when the POWER clause is omitted from a rebalance operation.
• ASM_DISKGROUPS - the list of disk groups that should be mounted by an ASM instance during instance startup, or by the ALTER DISKGROUP ALL MOUNT statement. ASM configuration changes are automatically reflected in this parameter.
• ASM_DISKSTRING - specifies a value that can be used to limit the disks considered for discovery. Altering the default value may improve the speed of disk group mount time and the speed of adding a disk to a disk group. Changing the parameter to a value which prevents the discovery of already mounted disks results in an error. The default value is NULL allowing all suitable disks to be considered.

Incorrect usage of parameters in ASM or RDBMS instances results in ORA-15021 errors.

To create an ASM instance first create a file called init+ASM.ora in the /tmp directory containing the following information.

   INSTANCE_TYPE=ASM

Next, using SQL*Plus, connect to the ide instance.

   export ORACLE_SID=+ASM
   sqlplus / as sysdba

Create an spfile using the contents of the init+ASM.ora file.

   SQL> CREATE SPFILE FROM PFILE='/tmp/init+ASM.ora';

   File created.

Finally, start the instance with the NOMOUNT option.

   SQL> startup nomount
   ASM instance started

   Total System Global Area  125829120 bytes
   Fixed Size                  1301456 bytes
   Variable Size             124527664 bytes
   Database Buffers                  0 bytes
   Redo Buffers                      0 bytes
   SQL>

The ASM instance is now ready to use for creating and mounting disk groups. To shut down the ASM instance, issue the following command:

   SQL> shutdown
   ASM instance shutdown
   SQL>

Once an ASM instance is present, disk groups can be used for the following parameters in database instances (INSTANCE_TYPE=RDBMS) to allow ASM file creation:

   * DB_CREATE_FILE_DEST
   * DB_CREATE_ONLINE_LOG_DEST_n
   * DB_RECOVERY_FILE_DEST
   * CONTROL_FILES
   * LOG_ARCHIVE_DEST_n
   * LOG_ARCHIVE_DEST
   * STANDBY_ARCHIVE_DEST

Startup and shutdown of ASM instances

ASM instance are started and stopped in a similar way to normal database instances. The options for the STARTUP command are:

   * FORCE - Performs a SHUTDOWN ABORT before restarting the ASM instance.
   * MOUNT - Starts the ASM instance and mounts the disk groups specified by the ASM_DISKGROUPS parameter.
   * NOMOUNT - Starts the ASM instance without mounting any disk groups.
   * OPEN - This is not a valid option for an ASM instance.

The options for the SHUTDOWN command are:

   * NORMAL - The ASM instance waits for all connected ASM instances and SQL sessions to exit then shuts down.
   * IMMEDIATE - The ASM instance waits for any SQL transactions to complete then shuts down. It doesn't wait for sessions to exit.
   * TRANSACTIONAL - Same as IMMEDIATE.
   * ABORT - The ASM instance shuts down instantly.

Administering ASM Disk Groups

Disks

Disk groups are created using the CREATE DISKGROUP statement. This statement allows specification of the level of redundancy:

   * NORMAL REDUNDANCY - Two-way mirroring, requiring two failure groups.
   * HIGH REDUNDANCY - Three-way mirroring, requiring three failure groups.
   * EXTERNAL REDUNDANCY - No mirroring for disks that are already protected using hardware mirroring or RAID.

In addition, failure groups and preferred names for disks can be defined. If the NAME clause is omitted the disks are given a system generated name like "disk_group_1_0001". The FORCE option can be used to move a disk from another disk group into this one.

   CREATE DISKGROUP disk_group_1 NORMAL REDUNDANCY
     FAILGROUP failure_group_1 DISK
       '/devices/diska1' NAME diska1,
       '/devices/diska2' NAME diska2,
     FAILGROUP failure_group_2 DISK
       '/devices/diskb1' NAME diskb1,
       '/devices/diskb2' NAME diskb2;

Disk groups can be deleted using the DROP DISKGROUP statement.

   DROP DISKGROUP disk_group_1 INCLUDING CONTENTS;

Disks can be added or removed from disk groups using the ALTER DISKGROUP statement. Remember that the wildcard "*" can be used to reference disks so long as the resulting string does not match a disk already used by an existing disk group.

   -- Add disks.
   ALTER DISKGROUP disk_group_1 ADD DISK
     '/devices/disk*3',
     '/devices/disk*4';

   -- Drop a disk.
   ALTER DISKGROUP disk_group_1 DROP DISK diska2;

Disks can be resized using the RESIZE clause of the ALTER DISKGROUP statement. The statement can be used to resize individual disks, all disks in a failure group or all disks in the disk group. If the SIZE clause is omitted the disks are resized to the size of the disk returned by the OS.

   -- Resize a specific disk.
   ALTER DISKGROUP disk_group_1
     RESIZE DISK diska1 SIZE 100G;

   -- Resize all disks in a failure group.
   ALTER DISKGROUP disk_group_1
     RESIZE DISKS IN FAILGROUP failure_group_1 SIZE 100G;

   -- Resize all disks in a disk group.
   ALTER DISKGROUP disk_group_1
     RESIZE ALL SIZE 100G;

The UNDROP DISKS clause of the ALTER DISKGROUP statement allows pending disk drops to be undone. It will not revert drops that have completed, or disk drops associated with the dropping of a disk group.

   ALTER DISKGROUP disk_group_1 UNDROP DISKS;

Disk groups can be rebalanced manually using the REBALANCE clause of the ALTER DISKGROUP statement. If the POWER clause is omitted the ASM_POWER_LIMIT parameter value is used. Rebalancing is only needed when the speed of the automatic rebalancing is not appropriate.

   ALTER DISKGROUP disk_group_1 REBALANCE POWER 5;

Disk groups are mounted at ASM instance startup and unmounted at ASM instance shutdown. Manual mounting and dismounting can be accomplished using the ALTER DISKGROUP statement as seen below.

   ALTER DISKGROUP ALL DISMOUNT;
   ALTER DISKGROUP ALL MOUNT;
   ALTER DISKGROUP disk_group_1 DISMOUNT;
   ALTER DISKGROUP disk_group_1 MOUNT;

Templates

Templates are named groups of attributes that can be applied to the files within a disk group. The following example show how templates can be created, altered and dropped.

   -- Create a new template.
   ALTER DISKGROUP disk_group_1 ADD TEMPLATE my_template ATTRIBUTES (MIRROR FINE);

   -- Modify template.
   ALTER DISKGROUP disk_group_1 ALTER TEMPLATE my_template ATTRIBUTES (COARSE);

   -- Drop template.
   ALTER DISKGROUP disk_group_1 DROP TEMPLATE my_template;

Available attributes include:

• UNPROTECTED - No mirroring or striping regardless of the redundancy setting.
• MIRROR - Two-way mirroring for normal redundancy and three-way mirroring for high redundancy. This attribute cannot be set for external redundancy.
• COARSE - Specifies lower granuality for striping. This attribute cannot be set for external redundancy.
• FINE - Specifies higher granularity for striping. This attribute cannot be set for external redundancy.

Directories

A directory hierarchy can be defined using the ALTER DISKGROUP statement to support ASM file aliasing. The following examples show how ASM directories can be created, modified and deleted.

   -- Create a directory.
   ALTER DISKGROUP disk_group_1 ADD DIRECTORY '+disk_group_1/my_dir';

   -- Rename a directory.
   ALTER DISKGROUP disk_group_1 RENAME DIRECTORY '+disk_group_1/my_dir' TO '+disk_group_1/my_dir_2';

   -- Delete a directory and all its contents.
   ALTER DISKGROUP disk_group_1 DROP DIRECTORY '+disk_group_1/my_dir_2' FORCE;

Aliases

Aliases allow the referencing of ASM files using user-friendly names, rather than the fully qualified ASM filenames.

   -- Create an alias using the fully qualified filename.
   ALTER DISKGROUP disk_group_1 ADD ALIAS '+disk_group_1/my_dir/my_file.dbf'
     FOR '+disk_group_1/mydb/datafile/my_ts.342.3';

   -- Create an alias using the numeric form filename.
   ALTER DISKGROUP disk_group_1 ADD ALIAS '+disk_group_1/my_dir/my_file.dbf'
     FOR '+disk_group_1.342.3';

   -- Rename an alias.
   ALTER DISKGROUP disk_group_1 RENAME ALIAS '+disk_group_1/my_dir/my_file.dbf'
     TO '+disk_group_1/my_dir/my_file2.dbf';

   -- Delete an alias.
   ALTER DISKGROUP disk_group_1 DELETE ALIAS '+disk_group_1/my_dir/my_file.dbf';

Attempting to drop a system alias results in an error.

Files

Files are not deleted automatically if they are created using aliases, as they are not Oracle Managed Files (OMF), or if a recovery is done to a point-in-time before the file was created. For these circumstances it is necessary to manually delete the files, as shown below.

   -- Drop file using an alias.
   ALTER DISKGROUP disk_group_1 DROP FILE '+disk_group_1/my_dir/my_file.dbf';

   -- Drop file using a numeric form filename.
   ALTER DISKGROUP disk_group_1 DROP FILE '+disk_group_1.342.3';

   -- Drop file using a fully qualified filename.
   ALTER DISKGROUP disk_group_1 DROP FILE '+disk_group_1/mydb/datafile/my_ts.342.3';

Checking metadata

The internal consistency of disk group metadata can be checked in a number of ways using the CHECK clause of the ALTER DISKGROUP statement.

   -- Check metadata for a specific file.
   ALTER DISKGROUP disk_group_1 CHECK FILE '+disk_group_1/my_dir/my_file.dbf'

   -- Check metadata for a specific failure group in the disk group.
   ALTER DISKGROUP disk_group_1 CHECK FAILGROUP failure_group_1;

   -- Check metadata for a specific disk in the disk group:
   ALTER DISKGROUP disk_group_1 CHECK DISK diska1; -- Check metadata for all disks in the disk group. ALTER   DISKGROUP disk_group_1 CHECK ALL;

ASM views

The ASM configuration can be viewed using the V$ASM_% views, which often contain different information depending on whether they are queried from the ASM instance, or a dependant database instance.

Views include:

• V$ASM_ALIAS Displays a row for each alias present in every disk group mounted by the ASM instance. Returns no rows
• V$ASM_CLIENT Displays a row for each database instance using a disk group managed by the ASM instance. Displays a row for the ASM instance if the database has open ASM files.
• V$ASM_DISK Displays a row for each disk discovered by the ASM instance, including disks which are not part of any disk group. Displays a row for each disk in disk groups in use by the database instance.
• V$ASM_DISKGROUP Displays a row for each disk group discovered by the ASM instance. Displays a row for each disk group mounted by the local ASM instance.
• V$ASM_FILE Displays a row for each file for each disk group mounted by the ASM instance. Displays no rows.
• V$ASM_OPERATION Displays a row for each file for each long running operation executing in the ASM instance. Displays no rows.
• V$ASM_TEMPLATE Displays a row for each template present in each disk group mounted by the ASM instance. Displays a row for each template present in each disk group mounted by the ASM instance with which the database instance communicates.

ASM Filenames

There are several ways to reference ASM file. Some forms are used during creation and some for referencing ASM files. The forms for file creation are incomplete, relying on ASM to create the fully qualified name, which can be retrieved from the supporting views. The forms of the ASM filenames are summarised below.

• Fully Qualified ASM Filename +dgroup/dbname/file_type/file_type_tag.file.incarnation
• Numeric ASM Filename +dgroup.file.incarnation
• Alias ASM Filenames +dgroup/directory/filename
• Alias ASM Filename with Template +dgroup(template)/alias
• Incomplete ASM Filename +dgroup
• Incomplete ASM Filename with Template +dgroup(template)

SQL and ASM

ASM filenames can be used in place of conventional filenames for most Oracle file types, including controlfiles, datafiles, logfiles etc. For example, the following command creates a new tablespace with a datafile in the disk_group_1 disk group.

   CREATE TABLESPACE my_ts DATAFILE '+disk_group_1' SIZE 100M AUTOEXTEND ON;

Migrating to ASM Using RMAN

The following method shows how a primary database can be migrated to ASM from a disk based backup:

   * Disable change tracking (only available in Enterprise Edition) if it is currently being used.

         SQL> ALTER DATABASE DISABLE BLOCK CHANGE TRACKING;

   * Shutdown the database.

         SQL> SHUTDOWN IMMEDIATE

   * Modify the parameter file of the target database as follows:
         o Set the DB_CREATE_FILE_DEST and DB_CREATE_ONLINE_LOG_DEST_n parameters to the relevant ASM disk groups.
         o Remove the CONTROL_FILES parameter from the spfile so the control files will be moved to
           the DB_CREATE_* destination and the spfile gets updated automatically. If you are using
           a pfile the CONTROL_FILES parameter must be set to the appropriate ASM files or aliases.

   * Start the database in nomount mode.

         RMAN> STARTUP NOMOUNT

   * Restore the controlfile into the new location from the old location.

         RMAN> RESTORE CONTROLFILE FROM 'old_control_file_name';

   * Mount the database.

         RMAN> ALTER DATABASE MOUNT;

   * Copy the database into the ASM disk group.

         RMAN> BACKUP AS COPY DATABASE FORMAT '+disk_group';

   * Switch all datafile to the new ASM location.

         RMAN> SWITCH DATABASE TO COPY;

   * Open the database.

         RMAN> ALTER DATABASE OPEN;

   * Create new redo logs in ASM and delete the old ones.

   * Enable change tracking if it was being used.

         SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING;

Functionality

ASM requires an ASM instance to manage diskgroups. DBAs can use SQL*Plus to connect to ASM and to do the usual database-level operations like startup and shutdown. However, one must set the ORACLE_SID variable to '+ASM' and not to the ORACLE_SID of a database. Views like V$ASM_DISK, V$ASM_DISKGROUP, V$ASM_FILE, V$ASM_ALIAS make it easier to perform queries regarding disk groups, disks in each disk group, their layout, extents etc.

Striping

ASM stripes its files across all the disks that belong to a disk group. It remains unclear if it follows a strict RAID 3 fashion of striping or a variant of RAID 3 that facilitates easy addition and removal of disks to and from the disk group. Oracle Corporation recommends that all the disks that belong to a disk group have the same size, in which case each disk gets the same number of extents. However, if a DBA configures disks of different sizes, each disk might get a different number of extents — based upon the size of the disk. An allocation unit typically has a size of 1MB.

ASM stripes help make data more reliably available and more secure than in other Oracle storage implementations.

Redundancy

One can configure ASM diskgroups to have no redundancy (external), two-way mirroring (normal), or three-way mirroring (high). In the case of normal and high mirrors, good practice suggests having fail groups that talk to different controllers for performance and fail-safe reasons.

• In the case of external redundancy, ASM does not do any software mirroring, but only stripes its files across all the disks that belong to the disk group that does external redundancy.
• In the case of normal redundancy, ASM does two-way mirroring, meaning that ASM maintains two copies of the data through software mirroring. When querying for mirror information, DBAs will see two mirrors in this case.
• In the case of high redundancy, ASM does three-way mirroring, maintaining three copies of the data through software mirroring. When querying for mirror information, DBAs will see three mirrors in this case.

Directory Structure

A typical directory of an ASM file looks like this:

+<DISKGROUP>/<ORACLE_SID>/<TYPE OF FILE>/file

Note that the root starts with '+' — for example:

+EXTERNAL/ORCL/DATA/system.54.1234567

Comparison with other LVMs

Other LVM	ASM
Volume Group	Disk Group
Volume	ASM File

Advantages for database administrators

• Database administrators see a familiar interface: SQL*Plus
• Interaction with ASM happens through commands that closely resemble standard SQL
• DBAs can assign data, log, control and other Oracle database files to a specific disk group without bothering about the physical location of the disks that constitute a disk group
• If a disk group runs out of space, an additional disk can be added to the disk group without bothering to copy/move data and without bothering where exactly data lives on the physical disks.

See also

• Logical volume management

External links

• http://twiki.cern.ch/twiki/pub/PSSGroup/Presentations2007/Inside_Oracle_ASM_LC_CERN_UKOUG07.ppt
• http://www.oracle.com/technetwork/issue-archive/2006/06-mar/o26asm-090635.html